Computer operating systems typically include a sub-system called a file system. A file system stores data in files. A file system provides an application programming interface (API) to facilitate accessing data stored on disk or other long-term storage medium. A file system API provides various functions that are invoked by an application program to access the data. Application programs control the internal format of a file and determine which data to store in which files. A file system typically allows files to be grouped into directories. Each directory may contain many files and many sub-directories. The sub-directories may also contain files and other sub-directories. A file system that groups files into directories and sub-directories is referred to as hierarchical file system.
Many application programs need to access various types of data. For example, word processing programs may combine data that is in text, graph, and spreadsheet format into a single document. A text format is known as the native format for word processing programs. A user of a word processing program may specify that graph or spreadsheet data that is stored in a file is to be included in the document. To do so, word processing programs may import data from files generated by a graph program or a spreadsheet program. Word processing programs typically need to know not only the internal format of the graphic and spreadsheet files, but also how to display or print the graph and spreadsheet data.
The marketability of a word processing program is enhanced by its ability to import data stored in many formats. However, it can be very time-consuming and expensive to adapt a word processing program to access data in a specific non-text format. To adapt to a word processing program, the developer would need a complete description of the specific format and then develop code to print, display, and possibly store the data. The effort needed to adapt a word processing program to a specific format is increased when the format is defined by another vendor. The vendor may not publish a complete specification of the format or may change the format without notice. Consequently, an application program developer may choose to support only a few of the more popular file formats other than the native file format.
One solution that has been suggested is that word processing programs invoke the application program that generated the data in the specific non-text format to display or print the non-text data that is part of a word processing document. For example, if a document incorporates a graph, then the word processing program would invoke the graph program that generated the data to print or display the graph or to perform some other task using the data. However, unless the graph program was developed specifically to be invoked by a particular word processing program, it may not be practicable to invoke the graph program. Graph programs typically expect data to be stored in a certain format and in a file with only graph data.
Several approaches have been suggested to allow a word processing program to invoke other programs to print, display, or otherwise process non-text data that is part of a word processing document. A first approach modifies each of the programs that generate the non-text data so that they know the internal format of the word processing document, can retrieve the non-text data from the document, and can process the retrieved data. This approach can be expensive because the programs would need to know the internal format for each word processing program.
A second approach stores each component of the word processing document in a separate file. Using this approach, data would be stored in the native format of each application program. Thus, the application program could be invoked to process the native data directly. However, this second approach jeopardizes the integrity of the word processing document. Users typically can delete a file using the operating system commands. A user could delete one of the files that is part of a word processing document. The word processing document would then have a link to a deleted file.
The problems encountered become complicated when the non-text data incorporated can additionally include other non-text data belonging to different programs. This situation is referred to as the arbitrary nesting of data. For example, a word processing document can contain a spreadsheet table which in turn contains a sound annotation. If a user wishes to edit the sound annotation, the word processing program invokes the spreadsheet program and tells it to invoke the sound editor. The sound editor must be able to locate its non-text data.
Additional complications occur if a user, by virtue of conceptually placing non-text data in a word processing document, expects to be able to edit the non-text data and only permanently save the changes when the user decides to save the changes to the word processing document. The programs invoked to process the non-text data must coordinate any changes made with the word processing program.
One approach is to modify each program to support a flag telling the program to save all changes to a designated temporary file. The word processing program is then responsible for overwriting the file containing the non-text data with the temporary file when it chooses to save the complete set of modifications to the word processing document.
Another approach is for the word processing program to save a snapshot of the non-text data file before it invokes the program to modify this data. The word processing program can then overwrite any changes made by the program invoked to process the non-text data if the user decides not to save the changes to the word processing document.